Nice work here. The core insight — deriving partial-tag detection from THINK_OPEN_TAG/THINK_CLOSE_TAG via lastIndexOf('<') instead of maintaining two hand-written prefix arrays — is a real quality win independent of the speedup: it removes a source of drift if the tag constants ever change, since previously PARTIAL_OPEN_PREFIXES/PARTIAL_CLOSE_PREFIXES had to be kept in sync by hand.

I traced through the getPartialTagLength rewrite against several edge cases (multiple < in the trailing window, strings shorter than 7 chars, suffix equal to the full tag) and it matches the original semantics in every case I checked — the lastIndexOf('<') approach is sound because a partial tag can't contain an embedded <, so the rightmost < is always the correct anchor.

The parseThinkTags cursor rewrite (replacing repeated remaining.slice(...) with indexOf(..., cursor) + index bookkeeping) is a straightforward, low-risk transformation and looks behaviorally identical to the slicing version.

Two things worth double-checking before this gets ported:

1. Confirm THINK_OPEN_TAG/THINK_CLOSE_TAG are exported/available in this file's scope with the values I assumed ('<think>', '</think>') — the diff doesn't show their definitions.
2. The benchmark numbers (2.91ms for 20k calls) suggest this is a very cheap hot path already; it'd help to know whether getPartialTagLength is actually called often enough in practice for this to matter, or whether the real win here is just the array removal/cleanup.

Overall this is a tight, single-purpose, tested diff with no behavior change — a reasonable candidate to port after re-verifying against the private tree's tag constants.